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Abstract 

This article proposes a new framework for a polytypic extension 
of functional programming languages. A polytypic functional pro- 
gram is one that is parameterised by datatype. Since polytypic func- 
tions are defined by induction on types rather than by induction on 
values, they typically operate on a higher level of abstraction than 
their monotypic counterparts. However, polytypic programming is 
not necessarily more complicated than conventional programming. In 
fact, a polytypic function is uniquely defined by its action on pro- 
jection functors and on primitive functors such as sums and prod- 
ucts. This information is sufficient to specialize a polytypic function 
to arbitrary datatypes, including mutually recursive datatypes and 
nested datatypes. The key idea is to use infinite trees as index sets 
for polytypic functions and to interpret datatypes as algebraic trees. 
This approach is simpler, more general, and more efficient than previ- 
ous ones that are based on the initial algebra semantics of datatypes. 
Polytypic functions enjoy polytypic properties. We show among other 
things that well-known properties of various functions are obtained as 
direct consequences of two polytypic fusion laws. 



1 



1 Introduction 



This article proposes a new framework for a polytypic extension of functional 
programming languages such as Haskell or Standard ML. The framework is 
simpler, more general, and more efficient than previous ones such as PolyP 
[14] that are based on the initial algebra semantics of datatypes. 

A polytypic function is one that is defined by induction on the structure of 
types. The archetypical example of a polytypic function is size :: F a — > Int, 
which counts the number of values of type a in a given value of type F a. 
The function size can sensibly be defined for each parameterised datatype 
and it is often — but not always — a tiresomely routine matter to do so. A 
polytypic programming language enables the user to program size once and 
for all times. The specialization of size to concrete instances of F is then 
handled automatically by the system. Polytypic programs are ubiquitous: 
typical examples include equality and comparison functions, mapping and 
zipping functions, pretty printers (such as Haskell's show function), parsers 
(such as Haskell's read function), data compression [17], and digital searching 
[11]. The ability to define such programs generically for all datatypes greatly 
simplifies the construction and maintenance of software systems. 

Since polytypic functions are defined by induction on types rather than 
by induction on values, they tend to be more abstract than their monotypic 
counterparts. However, once a certain familiarity has been gained, it turns 
out that polytypic programming is actually simpler than conventional pro- 
gramming. To support this claim let us define two simple functions, size 
and sum, for some illustrative datatypes. Examples are given in the func- 
tional programming language Haskell 98 [23]. As a first example, consider 
the datatype of rose trees. 



The size of a rose tree can be determined as follows, see, for instance [2]. 



data Rose a = Branch a (List (Rose a)) 
data List a = Nil \ Cons a (List a) 



sizer 

sizer (Branch a ts) 
list 

list <p Nil 

list ip (Cons a as) 



Rose a — > Int 

1 + suml (list sizer ts) 

(a — > a') — > (List a — > List a') 



Nil 



Cons (ip a) (list ip as) 
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sural :: List Int — > Int 

sural Nil = 0 

sural (Cons a as) = a + sural as 

The definition of sizer is already quite sophisticated: it makes use of the 
combining form list and the auxiliary function sural. The use of list, however, 
also incurs a slight run-time penalty: list produces an intermediate list, which 
is immediately consumed by sural. This inefficiency can be eliminated by 
fusing sural o list sizer into a single function (called sizef below). 

sizer :: Rose a — > Int 

sizer (Branch a ts) = 1 + sizef ts 

sizef :: List (Rose a) — > Int 

sizef Nil = 0 

sizef (Cons t ts) = sizer t + sizef ts 

Interestingly, this very definition naturally arises if we change the definition 
of rose trees to 

data Rose' a = Branch a (Forest a) 

data Forest a = Nil | Cons (Rose' a) (Forest a). 

The definition of surar :: Rose Int — > Int proceeds in an analogous 
fashion — it suffices, in fact, to replace '1' by 'a' in the definitions above. 

A slightly more complex datatype is the type of perfect binary search 
trees. 

data Perfect a k = Zero a \ Succ (Perfect (Node a k) k) 
data Node a k = Node a k a 

The definition of Perfect is somewhat unusual in that the recursive call on 
the right-hand side, Perfect (Node a k) k, is not identical to the left-hand 
side of the equation: Perfect is an example of a so-called nested datatype, a 
term coined by R. Bird and L. Meertens [5]. Since Perfect only encompasses 
perfect binary search trees, the size of a tree of type Perfect a a can be 
computed in logarithmic time. 

sizep :: Perfect a k — > Int 

sizep (Zero a) = 1 

sizep (Succ t) = 2 * sizep t + 1 
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The function sizep counts the number of values of type a in a tree of type 
Perfect a a. However, sizep cannot be assigned the type Perfect a a — > Int 
since the recursive call has type Perfect (Node a k) k — > Int. 
Summing up a perfect tree of integers is more challenging. 



sump 

sump (Zero a) 
sump (Succ t) 

sumn 

sumn (Node I k r) 
perfect 

perfect (pi (p 2 (Zero a) 
perfect <pi <p 2 (Succ t) 

node 

node ipi (p 2 (Node I k r) 



:: Perfect Int Int — > Int 



= a 



= sump (perfect sumn id t) 

:: Node Int Int — > Int 
= l+k+r 

:: (a -> a') —>(&—> k') 

— > (Perfect a k — > Perfect a' k') 
= Zero (ipi a) 

= Succ (perfect (node <pi (p 2 ) y?2 
:: (a -> a') -> (Jfc -> jfe') 

-> (A^ode a fc -> Me a' fc') 
= A^ode (</?i /) ((/9 2 fc) (vi r ) 



Note that perfect and node denote the mapping functions of the binary 
functors Perfect and Node. Improving the efficiency of sump by fusing 
sump o perfect sumn id is left as an exercise to the reader. 

Now, let us define size and sum once and for all times. To this end we 
must first take a closer look at the structure of types. Reconsider the datatype 
definitions given above. Haskell's data construct combines several features 
in a single coherent form: sums, products, and recursion. The structure of 
the types becomes more apparent if the definitions are rewritten as functor 
equations: 

Rose = Id x List ■ Rose 
List = Kl + Id x List 

Perfect = Fst + Perfect ■ (Node, Snd) 
Node = Fst x Snd x Fst, 

where K T is the constant functor, Id is the identity functor, Fst and Snd are 
projection functors, and F • (F ly . . . , F n ) denotes the composition of an n-ary 
functor F with n functors, all of the same arity. Sum and product are defined 
pointwise: (F 1 + F 2 ) T = F 1 T + F 2 T and (F 1 x F 2 ) T = F 1 T x F 2 T. 
In essence, functor equations are written in a compositional or 'point-free' 
style while data definitions are written in an applicative or 'pointwise' style. 
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We treat 1, '+', and 'x' as if they were given by the following datatype 
declarations. 

data 1 =() 

data ai + a 2 = Inl a\ \ Inr a 2 
data a\ x a 2 = (ax, a 2 ) 

To define size it suffices to specify its action on the identity functor, on 
constant functors, on sums, and on products. Polytypic functions are written 
using angle brackets to distinguish them from ordinary functions. 



size{F) 
size(Id) x 
size{KT) x 
size(F 1 + F 2 ) (Inl xx) 
size(F 1 + F 2 ) (Inr x 2 ) 
size{F 1 x F 2 ) (x u x 2 ) 



Ma.F a — > Int 

1 

0 

size (Fx) xi 
size(F 2 ) x 2 

size (Fx) xi + size(F 2 ) x 2 



Each equation is more or less inevitable: a value of type Id a = a contains 
one element of type a; a value of type KT a = T contains no elements. To 
determine the size of an element of type Fi a + F 2 a we must either calculate 
the size of a structure of type F\ a or that of a structure of type F 2 a. The 
size of a structure of type F\ a x F 2 a is given by the sum of the size of the 
two components. We can define size even more succinctly using a point-free 
style: 

:: Va.F a — > Int 
= const 1 
= const 0 

= size(F 1 ) V size(F 2 ) 
= plus o (size(Fi) x size(F 2 )), 

where plus (a, b) = a + b. The definitions of the other combining forms 
can be found in the appendix. Both styles have their pros and cons. The 
point-free style is usually more amenable to (mechanical) reasoning whereas 
the pointwise style is often more readable. 

Now, from the polytypic definition of size the following specializations 
can be automatically derived. 



size(F) 
size (Id) 
size(KT) 
size (F x + F 2 ) 
size (Fx x F 2 ) 
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sizeRose 

sizeRosei ip (Branch a ts) 
sizeListi ip Nil 
sizeListi ip (Cons a as) 
sizePerfect 

sizePerfect 2 (^1,^2) (Zero a) 
sizePerfect 2 ((^1,^2) (Succ i) 
sizeNode 2 ('Pi, ^2) (Node I k r) 



= sizeRosei (const 1) 

= ip a + sizeListi (sizeRosei ip) ts 

= 0 

= ip a + sizeListi ip as 

= sizePerfect 2 (const 1, const 1) 

= ifi a 

= sizePerfect 2 (sizeNode 2 (ifi, V2), V2) t 

= ipi I + ip 2 k + </?i r 



We postpone a detailed explanation of the specialization process until Sec- 
tion 4. For the moment it suffices to note that the different instances rigidly 
follow the structure of the respective datatypes. How do these functions 
relate to the handcrafted definitions? Now, sizeRose corresponds to the sec- 
ond, more efficient definition of sizer: we have sizer = sizeRosei (const 1) 
and sizef = sizeListi sizer. On the negative side, sizePerfect is a linear-time 
implementation as opposed to the logarithmic sizep. In general, a 'structure- 
strict', polytypic function has at least a linear running time. So we cannot 
reasonably expect to achieve the efficiency of a handcrafted implementation 
that exploits data-structural invariants. 

The polytypic definition of sum is equally simple. 

sum(F) :: F Int — > Int 

sum(Id) x = x 

sum(KT) x =0 

sum(Fi + F 2 ) (Inl xi) = sum(Fi) x\ 

sum(Fi + F 2 ) (Inr x 2 ) = sum(F 2 ) x 2 

sum(Fi x F 2 ) (xi,x 2 ) = sum(Fi) x\ + sum(F 2 ) x 2 

Specializing sum{F) to the various datatypes yields definitions similar to 
those obtained for size(F). In this case the generated functions are as efficient 
as the best handcoded implementations. 

The moral of the story so far: giving ad-hoc definitions of functions like 
size and sum is sometimes simple and sometimes involving. While the poly- 
typic definition is slightly more abstract, it is also to a high degree inevitable. 
It is this feature that makes polytypic programming light and sweet. 

The rest of this article is organized as follows. Section 2 reviews back- 
ground material from the theory of infinite trees. Section 3 introduces the 
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basic ingredients of polytypic programming: functor expressions and alge- 
braic trees. Section 4 explains how to specialize a polytypic function to 
concrete instances of datatypes. Polytypic functions enjoy polytypic proper- 
ties. Fixpoint induction on the functor level and fusion laws analogous to the 
fusion law for catamorphisms are described in Section 5. Section 6 presents 
several examples of polytypic functions and associated polytypic properties. 
Finally, Section 7 reviews related work and points out a direction for future 
work. 

2 Preliminaries 

This section introduces basic notions and facts from the theory of infinite 
trees as needed in the subsequent sections. For a more detailed survey the 
reader is referred to B. Courcelle's article [7], which also contains further 
references. 

A ranked set is a family (F k \ k G N) of pairwise disjoint sets F k of 
symbols of rank (or arity) k. Given a ranked set F of function symbols we 
denote by A(F) the set of all finite trees over F and by A°°(F) the set of 
all trees (finite and infinite) over F, see [7] for details. It is well-known that 
A(F) constitutes an initial algebra, which implies the following two facts. 

Fact 1 (Definition by structural induction) Given a set A and a 
family of functions ( Ja A x • • • x A — > A | / G F k ), there exists a unique 
function (p :: A(F) — > A such that 

<P(f(h,...,t k )) = fA(<p(t!),...,(p(t k )) 

for all k G N and / G F k . □ 

Fact 2 (Proof by structural induction) Let V C A(F) be a prop- 
erty of finite trees. To establish V(t) for all t G A(F) it suffices to show 

V(h) A • • • A V(t k ) =}► P(/(ti,...,t fc )) 
for all k G N and / G F k . □ 

The set of infinite trees A°°(F) can be turned into a complete partial 
order if we extend F by a new function symbol of arity 0, say, Q such that Q 
is the least element with respect to a suitably chosen partial order. The set 
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Figure 1: Types interpreted as infinite trees 



A°°(F U {fi}) even constitutes an initial continuous algebra, which implies 
the following two facts. 

FACT 3 Every monotone function tp :: A(F U {fi}) — > D, where D is a 
complete partial order, can be uniquely extended into a continuous function 
of type A°°(F U {VI}) — > D. □ 

Note that a function tp :: A(F) — > -D can be turned into a monotone function 
A(F U {fi}) — > -D by setting tp(fl) = _L, where _L is the least element of -D. 

A property P C A°°(F U {fi}) is called pointed if 7^(0); it is called 
chain-complete ttV(S) V(l}S) for every chain 5 C A°°(F U {Q}). 

Fact 4 Let P C A°°(i 71 U {fi}) be a pointed and chain-complete property of 
infinite trees. To establish V(t) for all t G A°°(F U {fi}) it suffices to show 
for all t E A(F). □ 



3 Datatypes as Algebraic Trees 

In the introduction we have seen that type definitions in Haskell take the 
form of recursion equations. If we interpret these equations syntactically, 
each equation defines a unique infinite functor tree. Figure 1 displays the 
trees defined by the type equations given in Section 1. Note that Rose 
is interpreted by a rational tree while Perfect denotes an algebraic tree. 
A rational tree is a possibly infinite tree that has only a finite number of 
subtrees. Algebraic trees are obtained as solutions of so-called algebraic 
equations, which are akin to functor equations defined below. 
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Given a ranked set of functor variables X and a ranked set of primitive 
functors P, the set of functor expressions of arity n is inductively defined as 
follows. 

F n ::= X" | 11? | P n | F fc • (F™, . . . , FJJ) | F n where D 

Here IT" denotes the n-ary projection functor selecting the i-th component. 
For unary and binary projection functors we use the following more familiar 
names: Id = Tl\, Fst = nf , and Snd = IT|. The expression F ■ (F\, . . . , Fj,) 
denotes the composition of a k-ary functor F with functors Fi, all of arity n. 
We omit the parentheses when k — 1 and we write F instead of F ■ () when 
k — 0. The keyword 'where' introduces local functor equations, where the 
set D of functor equations is given by the following grammar. 

D ::= {X fel = ¥ kl ; . . . ; X k " = ¥ k "} 

Note that Haskell does not provide local type declarations. We have included 
them, however, to make the language of functors more uniform. 

The choice of P is more or less arbitrary. For concreteness, we set P = 
P° U P 2 with P° = {Kl, KInt} and P 2 = {+, x}. As usual, binary functors 
are written infix, that is, we write i*\ © F 2 instead of © • (Fi, F 2 ) for © e P 2 . 

Each functor expression defines a unique infinite tree, called functor tree, 
whose inner nodes are labelled with primitive functors of arity ^ 1 and 
whose leaves are decorated with miliary functors and projection functors. 
In a sense, we can view infinite trees as a kind of 'infinite normal form' of 
functor expressions. Possibly infinite functor trees are formed according to 
the following grammar. 

T n ::= II? | P fc - (T",...,T£) 

Thus, P ■ (Ti,...,T fe ) with P E P fc corresponds to a tree, whose root is 
labelled with P and which has subtrees Ti, . . . , T fe , and n™ corresponds to a 
leaf. 

The functor tree denoted by a functor expression is given by 
{Xjrj = V (X) 

miv = n? 
{pj v = p.(n*,...,n{) 

lF-(F u ... : F k )jrj = iFjno ([F^,..., [F h U 
{F where X 1 = Fiji] = {Fjn^ := lfp(AT 1 .[F 1 ]ry(X 1 := T 1 ))). 
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Here 77 is an environment mapping functor variables to infinite functor trees 
and n(X := T) is syntax for extending the environment i] by the binding 
X := T. If the functor expression is closed, we omit the environment, that 
is, we write [F] instead of [F]r/. Functor composition is interpreted by a 
substitution operation on functor trees: 

fiou = n 
n?ou = Ui 

(P-(T 1 ,...,T k ))oU = P-(T 1 oU,...,T t oU), 

where U = (Lq, . . . , U n ). The first equation specifies that 'o' is strict in its 
first argument, the second defines the substitution of a leaf by a tree, and the 
third formalizes the propagation of a substitution to the subtrees of a node. 
Note that Fact 3 implies that 'o' can be uniquely extended to a continuous 
function on infinite functor trees. We will make use of the following properties 
of the substitution operation: 

To(n?,...,ns) = t (i) 

(To(T 1 ,...,T fe ))oU = To(T 1 oU,..,T fc oU). (2) 

The semantics of a functor equation is given by its least fixpoint (for reasons 
of readability we consider only single functor equations). Note that an equa- 
tion of the form X = P • (iq, . . . , Fk) with P e f k even has a unique solution 
in the realm of infinite trees [7]. 

Example 1 The functor equations X = X and X = X ■ X have the least 
solution Q (note that composition is strict in its first argument). □ 

Example 2 The unique solution of the functor equation Perfect = Fst + 
Perfect ■ (Node, Snd) is given by P 0 + (fq + (P 2 + • • •)), where P 0 = Fst 
and P n+ i = P n x Snd x P n . Thus, Perfect is the disjoint union of perfectly 
balanced trees of arbitrary height. □ 

Building upon the semantics we can classify functors into polynomial, 
regular, and nested functors. A functor is called polynomial if it denotes a 
finite functor tree. 

A = Idx Id 

Node23 = Fst x Snd x Fst + Fst x Snd x Fst x Snd x Fst 
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The functor A is called the diagonal or square functor; Node23 is used below 
in the definition of 2-3 trees. 

A regular functor is one that yields a rational functor tree. 

Bintree = Fst + Bintree x Snd x Bintree 

The functor Bintree models external, binary search trees. Further examples 
of regular functors are Rose, List, Rose', and Forest. 

The functor Perfect is an example of a non-regular or nested functor, 
which is interpreted by an algebraic functor tree. 

Sequ = Kl + Sequ ■ A + Id x Sequ ■ A 
Tree23 = Fst + Tree23 ■ {Node23, Snd) 

C. Okasaki [22] uses the functor Sequ as the basis for a sequence implemen- 
tation with an efficient indexing operation. The functor Tree23 models 2-3 
trees. The novelty of this definition is that the data-structural invariants of 
2-3 trees — each interior node has two or three children and each path from 
the root to a leaf has the same length — are made manifest. 

The same functor can usually be defined in a variety of ways. Take, for 
instance, the two definitions of rose trees given in Section 1. 

Rose = Id x List ■ Rose Rose' = Id x Forest 

List = Kl + Id x List Forest = Kl + Rose' x Forest 

Both Rose and Rose' denote the same rational tree depicted in Figure 1. 

Finally, let us note that the classification of functors into regular and 
nested functors deviates slightly from the usual notions. As an example, 
consider the following datatype definition. 

data ZigZag a b = Nil \ Cons a (ZigZag b a) 

Since the recursive call on the right-hand side of the 
definition, ZigZag b a, is not a copy of the left-hand 
side, ZigZag qualifies as a nested datatype. It denotes, 
however, the rational tree depicted on the right. An 
equivalent, non-nested definition for ZigZag is given by 

data Zig a b = Nil | Cons a (Zag a b) 
data Zag a b = Nil \ Cons b (Zig a b). 




Snd 
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While the standard classification of functors is purely syntactical — the form 
matters — , the classification via tree classes has a mild semantic flavour — the 
structure matters. 



4 Polytypic Functions 



We have already seen two examples of polytypic functions. In general, a 
polytypic function that is parameterised by m-ary functors is defined by 
induction on the structure of finite functor trees. 



The type of poly(T) is specified by the type scheme Poly(T), which may 
contain polymorphic types. Since poly is parameterised by m-ary functors, 
poly um must be specified for 1 ^ % ^ m. Furthermore, an equation specifying 
poly P must be given for each primitive functor P e P. Now, setting 



Fact 1 and Fact 3 imply that poly can be uniquely extended to a continuous 
function on infinite functor trees. We tacitly assume that poly U m and poly P 
are elements in some cpo (typically, they will be programs in Haskell or 
Standard ML). Fact 3 furthermore implies that the information above is 
sufficient to define a unique value poly(\F\) for each closed functor expression 
F. 

Example 3 The code of size given in the introduction defines the type 
scheme Size{F) = Wa.F a — > Int and the functions size id, sizexi, sizexint, 
size + , and size x . 



poly(T) 

poly(K) 

poly(P-(T 1 ,...,T k )) 



Poly(T) 
poly n ™ 

poly P (poly^), ■ ■ -,poly{T k )) 



poly(Q) = _L 



size u 



const 1 



sizeKi 



const 0 



sizexint = const 0 
size + (y?i,y? 2 ) = <fi V y? 2 
size x (vi, V2) = plus o (</?! x ip 2 ) 

Note that size(KT) specifies both sizexi and sizexint- □ 
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The question we pursue in this section is how to derive specializations of 
poly(\F\) for given instances of F. The process of specialization is necessary 
since poly(\F\) cannot directly be implemented in languages such as Haskell 
or Standard ML. The reason is simply that the type of poly depends on the 
first argument, which is itself a type (or possibly, the encoding of a type). 
Even if we circumvented this problem by using encodings into a universal 
datatype [27] or by using dynamic types and a typecase [1], the result 
would be rather inefficient because poly would interpret its type argument 
at each stage of the recursion. By specializing poly(\F\) for a given F we 
remove this interpretative layer. Thus, we can view the following as a very 
special instance of partial evaluation. 

Since datatypes correspond to algebraic trees, which may have an infi- 
nite number of different subtrees, the specialization cannot be based on the 
structure of datatypes. However, using functor expressions algebraic trees 
can be finitely represented so the idea suggests itself to carry out the spe- 
cialization on the representation of functor trees. The main challenge lies in 
the treatment of functor composition. Assume, for instance, that a unary 
functor is defined in terms of a binary functor: F = B ■ (i*\,i<2). Now, if 
we want to specialize size(\F\), how can we generate code for the right- 
hand side? Ideally, s^e([F]) should be compositionally defined in terms of 
the specializations for B, F\, and F 2 . Now, [5] is a binary functor map- 
ping (Ti, T 2 ) to [5] o (Ti, T 2 ). This suggests defining an auxiliary function 
size 2 {B} that maps (size (Ti) , size (T2)) to sue ([5] o (Ti, T 2 )) for all func- 
tor trees Ti and T 2 . We have seen that functor composition corresponds to 
a substitution operation on trees. Using the function size 2 (B} we imitate 
substitution on the function level. In general, we define, for each functor G 
of arity n, a polytypic function 

poly n (G)) :: VTi . . . T n .(Poly(T x ), . . . , Poly(T n )) - Poly{{G\ o (T u . . . , T n )) 
satisfying 

poly n (G} (poly(Ti), . . .,poly(T n )) = poly(\G\ o (Ti, . . . ,T n )), 

for all functor trees Ti, . . . , T n . For convenience we introduce the follow- 
ing abbreviations: T = (Ti, . . . , T n ) and poly(T) = (poly{Ti), . . . , poly(T n )). 
The specification captures the central idea of the specialization: the struc- 
ture of types is mimicked on the value level. Compare [G] and poly n (G}: 
[GJ is an n-ary functor sending T to [G] o T; likewise poly n (G} is an n-ary 
function sending poly(T) to poly(\G\ o T). 
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Now, before we get down to the derivation of poly n , we must first gener- 
alize the specification slightly. The equation above assumes that the functor 
expression G is closed. Of course, G may in general contain free functor 
variables. Thus, poly n must be extended by an environment mapping func- 
tor variables to continuous functions. Let g be such an environment and let 
r) be an environment mapping functor variables to infinite trees. The refined 
specification then reads: if g{X) (poly(T)) = poly(i](X) o T) for all free 
variables X of G, then 

poly n (G))g (poly (T» = poly(\G\ri o T). (specification) 

The condition relating g and i] is called the environment condition. The 
derivation of poly n {G} is a nice example in program calculation and proceeds 
almost mechanically. 

Case G = X: for functor variables we obtain 

poly n (X))g (poly{T)) 
= { specification } 

polydXjr, oT) 
= { definition of [-J } 

poly{r){X) oT) 
= { environment condition } 

g(X) (pe^T)). 

Case G = II": the derivation for projection functors is equally straightfor- 
ward. 

poly n m))g (poly{T)) 
= { specification } 

polydunv oT) 
= { definition of [-] and definition of 'o' } 

poly{T t ) 

Case G = P: for primitive functors we calculate 

poly n ((P))g (MKT)) 
= { specification } 
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poly{\P\n oT) 
= { definition of [-] and definition of 'o' } 

poly(P-T) 
= { definition of poly } 

poly P (poly(T)). 

Case G = H ■ (H 1 , . . . , H k ): the derivation for functor composition makes 
essential use of the fact that the substitution operation £ o' is associative. 

poly n (H-(H 1 ,...,H k )))g(poly{T)) 
= { specification } 

poly(lH.(H 1 ,...,H k )jr ] oT) 
{ definition of [-] and (2) } 

polydHjr) o ({H^rj o T, . . . , {H^ o T)) 
= { specification } 

poly k (H))g (polydH^ o T), . . . , poly(lH k j V o T» 
= { specification } 

poly k (H))g {poly^H^g (poly(T)), . . .,poly n (H k ))g (poly{T))). 

Case G = (H where Xi = Hi): the calculation for local functor equations 
proceeds as follows 

poly n (H where X 1 = H^g (poly(T)) 
= { specification } 

poly({H where X 1 = if J 77 o T) 
= { definition of [-J } 

polydHUXi := lip^. [ff^pd ■= Uj)) o T) 
= { specification and proof obligation } 

poly k (H))g(X 1 := Up(X^ 1 .poly kl (H 1 ))g(X 1 := ^i))) (poly(T)). 

The last step is not entirely obvious. To be able to apply the specification 
we have to prove that the extended environments satisfy the environment 
condition. If we define the relation V by 

Vty,U) 1>(poly{T))=poly{UoT), 
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then we have to show that 

V(Up(X^ 1 .poly kl (H l }g(X 1 := ^ 1 )),lft>(At/ 1 .[ff 1 ]|i 7 (X 1 := U 1 ))). 

In other words, we must show that least fixpoints are related. To this end 
we can use a 2-argument variant of fixpoint induction, which can be stated 
as the following inference rule: 

Q(_L,_L) \/v w.Q(v,w) ^> Q((p v,vp w) 

Q(lfp lfp J) ' 

Recall that fixpoint induction is only sound for chain-complete predicates. 
The predicate V satisfies this requirement since it takes the form of an equa- 
tion, which involves only continuous functions. Now, it is easy to see that V 
is pointed, that is, P(_L, Q). The induction step, where we have to show that 
V(ip,U) V{poly kl {H l ))g{X 1 := V), := CO), is a direct con- 

sequence of the specification; the assumption V(ip,U) guarantees that the 
extended environments q(X\ := vp) and r](Xi := U) satisfy the environment 
condition. 

Now, generalizing poly(T) to the tuple <p = (ifi, . . . , ip n ) we have calcu- 
lated the following definition of poly n . 

poiy n ( x ))e v = q( x ) v 
poly n { p }Q <p = poly? v 

poly n (H-(H 1 ,...,H k )))gcp 

= poly k ( H ))Q (poly n ( H i))Q <p, ■ ■ ■ , poly n ( H k))Q <p) 

poly n ((H where X 1 = H±}g if 

= poly k (H))Q(Xi ■= ltp(X^i.poly kl (H 1 }g(X 1 := Vi))) <P 
Using a point-free style poly n can be defined as 

poly n (X))g = g(X) 
poly n (Uf))g = tt" 

poly n (P}g = polyp 

poly n (H.(H 1 ,...,H k )))g 

= Poly k ((H}g-k (poly^H^g, poly n (H k ))g) 
poly n ((H where Xi = H^g 

= poly k (H))g(X 1 := Up(X^ 1 .poly kl (H 1 ))g(X 1 := Vi))), 
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where nf (<pi, . . . ,<p n ) = ipi is the i-th projection function and '*' denotes 
n-ary composition defined by (tp * (</?i, . . . , </?„)) a — ip (ipi a, . . . ,ip n a). It 
is worth emphasizing that the definition of poly n {G} is inductive on the 
structure of functor expressions. On a more abstract level we can view poly n 
as an interpretation of functor expressions: II" is interpreted by 7r™, P by 
poly P , '•' by V, and recursion by least fixpoints. 

It remains to define poly(\F\) in terms of poly m (F} — here we assume 
that P is closed: 

poly ({F ]> 

= {(1)} 

poly(lFjo(UT,...,U^)) 

= { specification } 

poly m (F)) (poly (H?),..., poly (1%)) 

= { definition of poly } 

Poly m {F} {poly UT , ■ ■ ■ , poly a™)- 
The following proposition summarizes the derivation. 

Proposition 1 (Correctness of the specialization) Let poly be a 
polytypic function parameterized by m-ary functors and let poly n be defined 
as above, then 

poly ( [P] ) = poly m ((F)) (poly UT ,..., poly uz ) 

for all closed functor expressions P of arity m. □ 

The above derivation takes place in a semantic setting, that is, complete 
partial orders and continuous functions. Of course, if we aim at implement- 
ing poly n , say, as a part of a preprocessor or a compiler, we must operate 
on a syntactic level, that is, we have to transform functor expressions into 
Haskell, Standard ML, or some intermediate language. Now, the syntactic 
variant of poly n {-}, which we denote poly n (-), simply works by mapping the 
different constructs in the functorial language to corresponding constructs in 
the expression language. For instance, recursion equations on the type level 
are mapped to recursion equations on the value level: 

/ X l = Pi \ polyX x = poly kl (F x )Q 

poly n I ■■■ \ g = ■■■ 

\ X p = X p I polyXp = poly kp (F p )g, 
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where g = q{X\ := polyXi, . . . ,X P := polyX p ) and ki is the arity of Xj. Note 
that the polyXi are expression variables. It is straightforward to define the 
remaining cases of poly n (-) such that £\poly n (F)\ = poly n {F}, where £ is 
the standard denotational semantics of expressions. The correctness of the 
transformation then follows immediately from Proposition 1. We leave it to 
the reader to fill out the details. 

Example 4 Let us specialize size to the datatypes Perfect and Node given 
by 

Perfect = + • [Uj, Perfect ■ (Node, H 2 2 )) 

Node = x • (n?, x • (n|,n?)). 

This system of functor equations can be mechanically transformed into the 
following system of function equations. 

sizePerfect 2 = size + * (nf, sizePerfect 2 * (sizeNode 2 , ify) 
sizeNode 2 = size x * (jrf, size x * (ir^, nf)) 

Expanding the definitions of 7r™, V, and size P we get 

sizePerfect 2 (^1,^2) = fi V sizePerfect 2 (sizeNode 2 (^1,^2)^2) 
sizeNode 2 (vi, V2) — plus o (</?i x p/fis o (<^ 2 x v^i))- 

Finally, if we use the original constructor names we obtain the Haskell code 
given in the introduction. □ 

It is worth mentioning that the specialization yields the same result for dif- 
ferent representations of the same functor tree, that is, 

{Fij = [F 2 ] =► poly n (F 1 )=poly n (F 2 ). 

This is a simple consequence of Proposition 1. Recall that [iZose] = [iZose'J. 
Consequently, we have sizex^Rose} = sizei(Rose'}. If we translate sizei{Rose} 
and sizei(Rose'} into Haskell, we obtain, of course, two different functions 
simply because Rose and Rose' are different types. In Haskell datatype dec- 
larations are generative, that is, each data declaration introduces a new 
distinct type. (If Rose and Rose' are defined within the same scope they 
even have to use different constructor names.) 
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5 Polytypic Properties 



This section investigates another facet of polytypism: polytypic reasoning. 
We show how to prove properties of polytypic functions using the principle 
of fixpoint induction and we present two polytypic fusion laws, analogous to 
the fusion law for catamorphisms. 

Fact 2 and Fact 4 suggest the following induction principle. Let V be a 
pointed and chain-complete property of functor trees of arity m. In order to 
prove that V holds for all functor trees, it suffices to show that 

P(7\) A ■ • • A V(T k ) V(P ■ (Ti, . . . , T k )). 

That is, P(n™) must hold for 1 ^ i ^ m and the implication must hold for 
each primitive functor P G P. 

Example 5 Assume that A is a parameterized type comprising only con- 
tainers of the same size, that is, size(A) = const a. Let us illustrate the 
induction principle by showing 

V(F) •<=>- size(F o A) = times a o size{F), 

where times a b = a * b. First of all, since times a is strict, we have that V 
is pointed. Since V takes the form of an equation, it is furthermore chain- 
complete. We show V(F) for F = Id and F = Fx x F 2 . The remaining cases, 
F = KT and F = Fi + F 2 , are left as exercises to the reader. 
Case F = Id: 

size(Id o A) 
= { definition of 'o' } 

size (A) 
= { assumption } 

const a 

= { arithmetic: a = a * 1 } 

times a o const 1 
= { definition of ' size'' } 

times a o size(Id). 
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Case F = F 1 x F 2 : 




A) 



size(F 1 o A x F 2 o A) 

{ definition of 1 'size' } 
plus o (size(F 1 o A) x size(F 2 o A)) 

{ ex hypothesi } 
plus o ((times a o size(Fi)) x (times a o size(F 2 ))) 

{ ' x ' respects composition } 
p/tts o (times a x times a) o (size(F\) x size(F 2 )) 

{ arithmetic: a*(& + c) = a*6 + a*c} 
times a o p/ns o (size(F 1 ) x size(F 2 )) 

{ definition of 'size 1 } 
times a o size(F x x F 2 ). □ 



Turning to the polytypic fusion laws let us remark beforehand that these 
laws are quite general. They hold for every polytypically defined function. 
This brings about a certain level of abstractness. It is likely that the reader 
will only fully acknowledge the value of these laws in Section 6 when we take 
a look at several examples. The first fusion law states conditions under which 
we can fuse a monotypic and a polytypic function, that is, ipopoly n ^G} ip = 
poly' n (G} (ipo<p) whereto y> is given by ipo(ip u . . . ,ip n ) = (ij}0(p u . . . , ipoip n ). 

Proposition 2 (Mono-poly fusion) Let poly n and poly' n be two poly- 
typic functions and let ip be a strict function. If ip o poly P «*p = poly'p (if) o cp) 
holds for all primitive functors P G P, then 



for all closed functor expressions G of arity n. 

Proof The structure of the proof is quite similar to the derivation of poly n . 
First of all, to be able to use induction over the structure of functor ex- 
pressions, we have to show a generalized statement: let g and g' be two 
environments such that ip o g(X) ip = g'(X) (ip o cp) for all free variables X 



tp o poly n (G)) ip 



poly' n {G)) (V o <p) 
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of G, then ip o poly n {G))g <p = poly' n {G))g' (if) o ip). 
Case G = X: 



= { definition of poly n } 

ip o e (X) v 
= { environment condition } 

g'(X) (^o^) 
= { definition of poly' n } 

poly' n (X))g' tyo V ). 

Case G = IT": 

ipopoly n (H?} e <p 
= { definition of poly n } 

= { definition of poly' n } 
poly' n (U-}g' t$o<p). 

Case G = P: 

i>°Poly n {P)Q <p 
= { definition of poly n } 

■ip o poly P (p 
= { assumption } 

poly' P (i/j o tp) 
= { definition of poly' n } 

poly'jPjg' t$o<p). 

Case G = H- (H ± , . . . , H k ): 

i\) o poly n (H -(H u ..., H k )))g cp 
= { definition of poly n } 

ip o poly k (H))g (poly n {Hi}g <p,..., poly n (H k ))g if) 
= {ex hypothesi } 
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Voly' k {H))Q O o poly^Hijg <p, . . . , ip o poly n (H k ))g ip) 
= {ex hypothesi } 

poly' k (H))g' (poly'AH^g' o <p), . . . ,poly' n (H k ))g' o tp)) 
= { definition of poly' n } 

poly' n {H-{H u ...,H k )))e' (ipoip) 

Case G = (H where X 1 = H^: 

ip o poly n ([H where Xi = Hi}g ip 
= { definition of poly n } 

iP o poly n ((H))g(X l := lfp(Xip 1 .poly kl ((H 1 ))g(X 1 := ^))) ^ 
= {ex hypothesi and proof obligation } 

poly' n {H}(J{X x := lfp(A^V fel «#i>y (*i := iP[))) (V> ° ¥>) 
= { definition of poly' n } 

poly'jH where X l = H.jg' (ip o ip) 

It remains to show that the extended environments satisfy the environment 
condition. If we define V by 

V(p,p) ipo P ip = p' (ipotp), 

then we have to show that 

V(lfp(XiP 1 .poly kl ((H 1 ))g(X 1 := iP 1 )),lfp(XiP' 1 .poly' kl ((H 1 ))g'(X 1 := ^))). 

The straightforward fixpoint induction is omitted (but note that V is pointed 
since ip is strict). □ 

Example 6 To illustrate the first fusion law let us show 

length o flatten (F) = size(F). 

The polytypic function flatten(F), which listifies a given structure, is defined 
as follows 

flatten(F) :: Va.F a — ■> List a 

flatten (Id) = wrap 

flatten(KT) = const [ 

flatten (F 1 + F 2 ) = flatten (F t ) \/ flatten (F 2 ) 

flatten (Fx x F 2 ) = cat o (flatten (Fi) x flatten(F 2 )), 
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where wrap a = [a] and cat (x, y) — x -H- y. By Proposition 2 we know 

length o flatten i{F} wrap = size i{F} (length o wrap), (3) 

provided that 

length o const [] = const 0 
length o (ip ± v y^) = (length o v (length o <^ 2 ) 
length o cat o x </? 2 ) = plus o ((length o y?]^) x (length o </3 2 ))- 

All three conditions hold — the relevant laws are listed in the appendix. Not- 
ing that lengthowrap = const 1 the proposition follows immediately from (3). 
□ 

The second polytypic fusion law states conditions under which a compu- 
tation of two polytypic functions can be fused into a single polytypic function. 
Setting (</?!, ...,</?„) o ip n ) = (</?! o ^, ...,</?„ o tp n ), we have 

Proposition 3 (Poly-poly fusion) Let poly n , poly' n , and poly" n be three 
polytypic functions. If poly P (p o poly' P if) = poly" P ((p o if)) holds for all 
primitive functors P G P, then 

poly n {G))^opoly' n {G))il) = poly'^G)) {tp o ^) 

for all closed functor expressions G of arity n. 

This law is proved in the same way as Proposition 2. 

Applications of the second fusion law will be given in the following section. 

6 Examples 

This section presents further examples of polytypic functions and associated 
polytypic properties. Note that most of these functions arise as generaliza- 
tions of corresponding list processing functions. 

6.1 Mapping Functions 

In categorical terms a functor is the combination of a parameterized type and 
a mapping function, which describes the action of the functor on functions. 
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The mapping function of a unary functor F applies a given function to each 
element of type a in a given structure of type F a. The polytypic variant of 
the mapping function is given by 1 



fmap(F) :: Va a 1 .{a -> a') -> (F a -> F a') 

fmap(F) <f = map{F) 

where map(F) :: F a —> F a' 

map (Id) = (p 

map(KT) = id 

map(Fi + F 2 ) = map(Fi) + map(F 2 ) 

map(Fi x F 2 ) = map(Fi) x map(F 2 ). 

It is revealing to consider the typings of the subsidiary functions ma|? r 



map n {G)) :: V7\ ... r n .(Ti a -> J\ a' , . . . , T n a -> T n a') 

-^(G(T ia ) ... (T n a)-^G(r 1 a') ... (T n a')) 

Replacing a by and T{ a' by we obtain the typings of n-ary mapping 
functions. And, in fact, map n (G} corresponds to the mapping function of 
the n-ary functor G. Thus, to define fmap generically for all unary functors, 
mapping functions of functors of arbitrary arity are required. The good news 
is that the programmer need not take care of their definition. Instead, they 
are generated automatically. 

The mapping function of a unary functor is required to satisfy the follow- 
ing two functorial properties. 

fmap(F) id = id 
fmap(F) (if o ip) = fmap (F) ip o fmap (F) ip. 

The first property can be shown using fixpoint induction. Only the proof of 
fmap(Q) id = id requires a bit of fudging. We have that fmap(Q) = _L so 
we must in effect show that _L = id. This equation holds, however, since Q 
accommodates only the bottom element (recall that we are working in a 
cpo setting). The second property is an instance of the second polytypic 
fusion law. Setting poly n = poly' n = poly" n = map n , we must establish 

1 We assume that type variables appearing in type signatures are scoped, that is, the 
type variables a and b in the signature of map(F) are not universally quantified but refer 
to the occurrences in fmap(F)'s signature. 
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mapp (pomapp ip = map P {ipoxj}) for map KT = id, map + (p\,p 2 ) = P1 + P2, 
and map x (pi,p 2 ) = p>i x p 2 . All of these conditions hold. 

So far we have excluded types that contain function spaces. Perhaps 
surprisingly, our approach to polytypic programming works equally well if P 2 
additionally includes the function space constructor. We have only omitted 
'— >' because most of the polytypic functions cannot sensibly be defined for 
the function space. For instance, fmap cannot be defined for functional types 
since '— >' is contravariant in its first argument: 

(-) :: (a' - a) - (6 - V) - ((a - 6) - (a' - 6')) 

Now, drawing from the theory of embeddings and projections [9] we can 
remedy the situation as follows. The central idea is to supply a pair of 
functions where 7r is the left-inverse of i, that is, n o % = id. If the 

functions additionally satisfy i o n □ id, then (i, it) is called an embedding- 
projection pair. Given this notion we can define a variant of fmap, which 
additionally works for the function space constructor: 

mapE(F) 
mapE{Id) ip 
mapE (K T) ip 
mapE(Fi + F 2 ) <p 
mapE(F 1 x F 2 ) p 
mapE{Fi F 2 ) p 

where apply (i,ir) = % and («, 7r)° = Now, assume that p is an 

embedding-projection pair, then we can prove 

mapE(G) p° o mapE(G) p = id 

by fixpoint induction. We confine ourselves to the interesting cases. 
Case G = Id: 

mapE(Id) p° o mapE(Id) (p 
= { definition of mapE } 

apply p° o apply p 
= { definition of apply and definition of p° } 



:: Va a'. (a -> a 1 , a' -> a) -> (F a -> F a') 

= app/y (/? 

= i<i 

= mapE(F 1 ) p + mapF(F 2 ) 

= mapE(F 1 ) p x mapE(F 2 ) p 

= mapE(F 1 ) p° — > mapE(F 2 ) p>, 
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7T o % = id 

= { ip is an embedding-projection pair } 
id. 

Case G = F x -> F 2 : 

mapE(F 1 — > F 2 ) y?° o mapE(Fi — > F 2 ) y? 
= { definition of mapE } 

(mapE(Fi) (y?°)° — > mapE(F 2 ) <p°) o (mapE(Fi) ip° mapE(F 2 ) (p) 
= { definition of '— >' } 

\h.mapE(F2) <p° o (mapE (F2) <p o h o mapE(Fi) ip°) o mapE(Fi) ((fi°)° 
= {ex hypothesi and (y?°)° = V 9 } 

Using similar calculations we can furthermore show that 

mapE(G) ip o mapE(G) ip° C zd. 

Both laws imply that (mapE(G) ip, mapE(G) ip°) is again an embedding- 
projection pair. Finally one can show that Ay? — > (mapE{G) if, mapE(G) ip°) 
is the functorial action of G in the category CPO B of complete partial orders 
and embedding-projection pairs. 

Another variant of fmap is the so-called monadic map [8]. Before we 
discuss its definition let us briefly review the basics of monads. For a more 
in-depth treatment we refer the interested reader to P. Wadler's papers [24, 
25, 26]. One can think of a monad as an abstract type for computations. In 
Haskell monads are captured by the following class declaration. 

class Monad m where 
return :: a — > m a 
(»=) :: ma^(a^mb)^>mb 

The essential idea of monads is to distinguish between computations and 
values. This distinction is reflected on the type level: an element of m a 
represents a computation that yields a value of type a. A computation 
may involve, for instance, state, exceptions, or nondeterminism. The trivial 
computation that immediately returns the value a is denoted return a. The 
operator (»=) combines two computations: m ^= k applies k to the result 
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of the computation m. Several datatypes have a computational content. For 
instance, the type Maybe given by 

data Maybe a = Nothing \ Just a 

can be used to model exceptions: Just x represents a 'normal' or successful 
computation yielding the value x while Nothing represents an exceptional or 
failing computation. The following instance declaration shows how to define 
return and (>■=) for Maybe. 

instance Monad Maybe where 
return = Just 

Nothing ~^*= k = Nothing 
Just a >■= k = k a 

Thus, m >>= k can be seen as a strict postfix application: if m is an exception, 
the exception is propagated; if m succeeds, then k is applied to the result. 

The definition of fmap makes use of the combining forms '+' and 'x'. 
The monadic mapping function can be succinctly defined if we raise these 
combinators to procedures, where a procedure is a function that maps values 
to computations. In other words, a procedure is a function of type a — > M b 
where M is a monad. 

mmap :: (Monad m) =>- (a — > a') — > (m a — > m a') 

mmap ip m = m s= (return o tp) 

(EH) :: (Monad m) =>- (a — > m a') — > (b — > m 6') 

-> (a + & -> m (a' + 6')) 
(/ii EEI h 2 ) (Inl xi) = mmap Inl (hi x\) 
(hi EEI h 2 ) (Inr x 2 ) = mmap Inr (h 2 x 2 ) 

(E) :: (Monad m) =>• (a — > m a') — > (6 — > m &') 

— > (a x & — > m (a' x &')) 
(/ii IE /i 2 ) (xi, x 2 ) = /ii Xi »= Ayi h 2 x 2 ^= Xy 2 — > reinrn y 2 ) 

Given these combinators the definition of the monadic map is straightfor- 
ward. 

mapMl(F) :: Va a' .(Monad m) =>- (a — > m a') — > (F a — > m (F a')) 

mapMl(Id) ip = ip 

mapMl(KT) ip = return 

mapMl(Fi + F 2 ) ip = mapMl(Fi) <p EB mapMl(F 2 ) p 

mapMl(Fi x F 2 ) ip = mapMl(Fi) p E mapMl(F 2 ) p 
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Note that the letter '/'in mapMl indicates that the structure F a is tra- 
versed from left to right. The dual function, mapMr, is defined completely 
analogously except that in the definition of W the computations hi X\ and 
h 2 x 2 are reversed. For applications of monadic maps we refer the interested 
reader to the tutorial of E. Meijer and J. Jeuring [21]. 



6.2 Reductions 

The functions size, sum, and flatten are instances of a more general concept, 
due to L. Meertens [19], termed reduction or crush. A reduction is a function 
of type F a — > a that collapses a structure of values of type a into a single 
value of type a. To define a reduction two ingredients are required: a value 
e :: a and a binary operation op :: a — > a — > a. Usually but not necessarily e 
is the neutral element of op. 

reduce(F) :: Wa.a — > (a — > a — > a) — > (F a — > a) 

reduce{F) e op = red(F) 

where red{F) :: F a — > a 

red (Id) x = x 

red(KT) x = e 

red(F 1 + F 2 ) (M xi) = red(F 1 ) Xl 

red(F\ + F 2 ) (Inr x 2 ) = red(F 2 ) x 2 

red(Fi x F 2 ) (x 1 ,x 2 ) = red(F 1 ) x\ l op l red(F 2 ) x 2 

Using a point free style we can define the helper function red more succinctly. 



red (Id) = id 

red(KT) = const e 

red(F 1 + F 2 ) = red(F 1 ) V red(F 2 ) 

red(F 1 x F 2 ) = uncurry op o (red(F 1 ) x red{F 2 )) 

A number of useful functions can be implemented in terms of reduce and 
fmap, see Figure 2. L. Meertens [19], P. Jansson and J. Jeuring [16] give 
further applications. 

Again, it is interesting to inspect the subsidiary functions reduce n given 
by reduce n (G} e op = red n {G} more closely. The following property 

reduce n {G} e op (<p o t/?) = reduce n {G} e op ip o map n {G} if), 
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sum(F) :: \/n.(Num n) =>- F n — > n 

sum(F) = reduce{F) 0 (+) 

and(F) :: F Bool -> 5oo/ 

and(F) = reduce(F) True (A) 

minimum{F) :: V a. {Bounded a, (3rd a) =>- F a — > a 

minimum{F) = reduce(F) maxBound min 

size(F) :: Va n.(Num n) =>- F a — > n 

size(F) = sum{F) o fmap(F) (const 1) 

aZZ(F) :: V 'a.(a -> Boo/) -> (F a -> 5ooZ) 

all(F) p = and(F) o fmap(F) p 

flatten(F) :: Va.F a — * Lzsi a 

flatten(F) = reduce(F) [] (-H-) ofmap(F) wrap 

data Tree a = Empty \ Leaf a \ Fork (Tree a) (Tree a) 

shape{F) :: Va.F a — ► Tree a 

shape{F) = reduce(F) Empty Fork o j 'map (F) Leaf 



Figure 2: Examples of reductions. 

which is an immediate consequence of Proposition 3, shows that reduce n 
combines a reduction with a map. This idiom is, in fact, a very old one. It 
appears, for instance, in R. Bird's lectures [6] where it is shown that each 
homomorphism on lists (that is, each catamorphism) can be expressed in this 
form. In a sense, reduce n can be seen as a generalization of that scheme. 

Specializing Proposition 2 gives an important fusion law for reductions. 
Let ip be a strict function, then 

ip e = e A ip (op xi x 2 ) = op' (ip x\) (ip x 2 ) 
=^> ip o reduce n {G} e op ip = reduce n (G} e op 1 (if) o <p). 

An immediate consequence of the two fusion laws for reductions is, for in- 
stance, length o flatten (F) = size(F), see Example 6. 

The implementation of flatten given in Figure 2 has a quadratic running 
time since the computation of x -H- y takes time proportional to the length of 
x. Using the well-known technique of accumulation [2] we can improve the 
running time to 0(n). The basic idea is to define a function redr{F) such 
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that 

op (red{F) x) a = redr(F) x a. 
In a point-free style this condition can be written more succinctly as 

opored(F) = redr(F), 

which suggests to apply Proposition 2 for deriving a definition of redr(F). 
The calculation, which is left as an exercise to the reader, shows that the 
following definition improves reduce{F) provided op is associative and e is 
the neutral element of op. 



reduce (F) 

reduce (F) e op x 
where redr(F) 
redr(Id) 
redr(KT) 
redr(F 1 + F 2 ) 
redr(F 1 x F 2 ) 



Va.a — > (a — > a — > a) — > (F a — > a) 
redr{F) x e 
F a — > (a — > a) 
op 

const id 

redr(Fi) V redr{F 2 ) 

uncurry (o) o (redr(Fi) x redr{F 2 )) 



The implementation guarantees that applications of op are only nested to 
the right as in op ai (op a 2 (• • • (op a n e) • • •)) — hence the name of the 
auxiliary function. This property also reveals that the type of reduce' (F) is 
unnecessarily restricted: the two arguments of op need not have the same 
type. Therefore, we may generalize the type signature as follows. 



reducer (F) 

reducer (F) op 
where redr(F) 
redr{Id) 
redr(KT) 
redr{Fi + 
redr{F\ x 



F 2 ) 
F 2 ) 



Wa b.(a -> (b -> b)) -> (F a -> (6 -> 6)) 
re<ir(i ? ) 

op 

const id 

redr(Fi) V redr{F 2 ) 

uncurry (o) o (redr(Fi) x redr{F 2 )) 



Note that we have rearranged the arguments to emphasize the structure. 
Building upon reducer (F) we can now give a linear-time program for flatten {F) . 



flatten(F) 
flatten(F) x 



Va.F a — > Lzst a 
reducer(F) (:) x [ j 
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Finally, note that reducer is equivalent to an fmap followed by an 'ordinary' 
reduction. We have 

reducer(F) op = reduce(F) (o) id o fmap (F) op, 

which can be shown using Proposition 3. 



6.3 Equality and Comparison Functions 

The equality function is a nice example of a function that is indexed by a 
nullary functor. In Haskell it can be automatically derived for datatypes 
of first-order kind and the following can be seen as a formalization of that 
process. We assume that a suitable equality function for Int is predefined. 

eq(T) :: T -> T -> Bool 

eq(Kl) x y = True 

eq(KInt) x y = eqlnt x y 

eq{T x + T 2 ) (Inl x x ) (Inl 2/1) = eq{T x ) x x y 1 

eq(Ti + T 2 ) (Inl x±) (Inr y 2 ) = False 

eq{Ti + T 2 ) (Inr x 2 ) (Inl y±) = False 

eq(T 1 + T 2 ) (Inr x 2 ) (Inr y 2 ) = eq(T 2 ) x 2 y 2 

eq(T! x T 2 ) (x u x 2 ) (y ± , y 2 ) = eq(Ti) x x y x A eq(T 2 ) x 2 y 2 

Note that eq unlike fmap and reduce cannot be defined in a uniform way 
for all constant functors. Functions that are indexed by nullary functors 
typically require a case analysis on constant functors. 

Varying the definition of eq slightly we can also realize Haskell's compare 
function, which determines the precise ordering of two elements. 



data Ordering 

cmp{ T) 
cmp(Kl) x y 
cmp(KInt) x y 
cmp{Ti + T 2 ) (Inl x±) (Inl y±) 
cmp(T\ + T 2 ) (Inl x\) (Inr y 2 ) 
cmp(T x + T 2 ) (Inr x 2 ) (Inl Vl ) 
cmp(Ti + T 2 ) (Inr x 2 ) (Inr y 2 ) 
cmp{T x x T 2 ) (x 1 ,x 2 ) (2/1,2/2) 



LT I EQ I GT 

T -> T -> Ordering 
EQ 

cmplnt x y 
cmp(Ti) x x 2/1 
LT 
GT 

cmp(T 2 ) x 2 2/2 

case cmp(Ti) x\ y\ of 

{EQ — > cmp(T 2 ) x 2 2/2; ord — > ord} 
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6.4 Zipping Functions 



Closely related to mapping functions are zipping functions. A zipping func- 
tion takes a pair of structures and returns a structure of pairs. If the ar- 
gument structures have not the same shape, the zipping function returns 
Nothing (which we abbreviate by fail); otherwise it yields Just z where z 
is the desired structure. In other words, the zipping function uses the ex- 
ception monad Maybe to signal incompatibility of argument structures. The 
definition of zip is similar to that of eq and cmp. 



zip{F) :: Va b.F a -> F b -> Maybe (F (a, b)) 

zip(Kl) x y = return () 

zip(KInt) x y = if eqlnt x y then return x else fail 

zip {Id) x y = return (x, y) 

zip{Fi + F 2 ) (Inl xi) (Inl y x ) = mmap Inl (zip{F 1 ) x 1 yi) 

zip(Fi + F2) (Inl x\) (Inr y 2 ) = fo.il 

zip(F\ + F 2 ) (Inr x 2 ) (Inl y\) = fail 

zip{Fi + F 2 ) (Inr x 2 ) (Inr y 2 ) = mmap Inr (zip(F 2 ) x 2 y 2 ) 
zip(F 1 x F 2 ) (xi, x 2 ) (yi, y 2 ) = zip(F 1 ) x x y x ^ \z x ->• 

zip(F 2 ) x 2 y 2 ^= Xz 2 

return (z±, z 2 ) 

Note that the type of zip could be generalized to arbitrary monads that 
contain a zero element such as fail. 



7 Related and Future Work 

This article can be regarded as a successor to my previous work on polytypic 
programming [10], where a similar approach using rational trees is presented. 
The major difference between the two frameworks lies in the treatment of 
functor composition. In the 'rational tree approach' functor composition is 
regarded as a function symbol, which implies that a polytypic definition must 
specify the action on G ■ (G±, . . . , G n ) for each n ^ 1. Clearly, this cannot 
be done exhaustively. Furthermore, since the cases for functor composition 
are redundant, there is no guarantee that the polytypic function behaves the 
same on equal functors such as Rose and Rose'. Both problems disappear if 
we handle functor composition on the meta level generalizing rational trees 
to algebraic trees. 
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The classic approach to polytypic programming as realized in the poly- 
typic programming language extension PolyP [14] is based on the initial 
algebra semantics of datatypes. Here, functors are modeled by the following 
grammar. 

F ::= fjM 

B ::= KT \ Fst \ Snd |B + B|BxB|F-B 

Recursive datatypes are modeled by fixpoints of associated base functors: the 
functor jiB, which is known as a type functor, denotes the unary functor F 
given as the least solution of the equation F a = B(a,F a). Polytypic 
functions are defined according to the above structure of types. In PolyP the 
polytypic function size{F) is defined as follows — modulo change of notation. 



size(F) :: \/a.F a — > Int 

size(/iB) = cata(fj,B) (bsize{B)) 

bsize(B) :: Wa.B a Int — > Int 

bsize(KT) x =0 

b size {Fst) x =1 

bsize(Snd) n = n 

bsize{B\ + B 2 ) (Inl xi) = bsize(Bi) x\ 

bsize{B\ + B 2 ) (Inr x 2 ) = bsize(B 2 ) x 2 

bsize{Bi x B 2 ) (xi,x 2 ) = bsize(Bi) x x + bsize(B 2 ) x 2 

bsize{F • B) x = sum{F) (fmap(F) (bsize(B)) x) 

The program is quite elaborate as compared to the one given in Section 1: 
it involves two general combining forms, cata and fmap, and an auxiliary 
polytypic function, sum. The disadvantages of the initial algebra approach 
are fairly obvious. The above definition is redundant: we know that size is 
uniquely defined by its action on constant functors, Id, sums, and products. 
The definition is incomplete: size is only applicable to regular functors (recall 
that, for instance, Perfect is not a regular functor). Furthermore, the regular 
functor may not depend on functors of arity ^ 2 since functor composition 
is only defined for unary functors. Finally, the definition exhibits a slight 
inefficiency: the combing form fmap produces an intermediate data struc- 
ture, which is immediately consumed by sum. In other words, size(Rose) 
corresponds to the first, less efficient definition of sizer. 

Unlike the framework we have presented so far PolyP allows the program- 
mer to define general recursion schemes like cata- and anamorphisms [20]. 
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As an example, the recursion scheme cata, which is used in size, is given by 



cata{F) 
cata{jj,B) ip 



Wa b.(F' ab^b)^(F a ^ b) 
p o bmap(B) id (cata(/iB) ip) o out. 



The operation (-)', which is called FunctorOf in PolyP, maps a type func- 
tor to its base functor: F' = B for F = fiB. The function out :: F a — > 
F' a (F a) decomposes an element of type F a by unfolding one level of 
recursion. While the explicit treatment of type recursion is unnecessary for 
many applications — all polytypic functions of PolyLib [16] can be imple- 
mented in our framework, except, of course, cata- and anamorphisms — it is 
indispensable for others. The polytypic unification algorithm described by 
P. Jansson and J. Jeuring [15], for instance, requires a function that deter- 
mines the immediate subterms of a term. A similar function appears in the 
article of R. Bird, O. de Moor, and P. Hoogendijk [4], who present a gener- 
alization of the maximum segment sum problem. In both cases the recursive 
structure of a datatype must be known. 

Now, since our framework deals with type recursion on the meta level, one 
could feel tempted to conclude that we cannot deal with such applications. It 
appears, however, that the availability of operations on types is an orthogonal 
design issue. Hence, nothing prevents us from incorporating the operator (-)' 
depicted above. To this end we simply take over the type inference algorithm 
described by P. Jansson and J. Jeuring [14]. It is useful to generalize (-)' so 
that it maps an n-ary, regular functor to its associated (n + l)-ary base func- 
tor. Given two polytypic functions inv.F' a\ . . . a n (F a± . . . a n ) — > F a± . . . a n 
and out :: F a± . . . a n — > F' a± . . . a n (F a\ . . . a n ) we can define cata- and 
anamorphisms for functors of arbitrary arity. Here are the definitions for 
unary functors. 



It is worth noting that the definition of the subsidiary function bmap proceeds 
as before. In particular, there is no need to consider functor composition or 
type functors. Furthermore, the base functor may be a nested functor. The 
function that collects the immediate subterms of a term can be defined as 



cata(F) 
cata{F) p 

ana{F) 
ana(F) ip 



Va b.(F' ab^b)^(F a^b) 
p o bmap(F') id (cata(F) p) o out 



Va b.(b -> F' ab) -> (b -> F a) 
in o bmap{F') id (ana{F) ip) o ip 
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follows. 

subterms(T) :: T — > List T 
subterms(T) = flatten (T 1 ) o out 

A direction for future work suggests itself: it remains to broaden the 
approach to include higher-order polymorphism [18]. Currently, the author is 
working on an extension so that polytypic functions can be defined generically 
for all datatypes expressible in Haskell. First results are summarized in [12]. 
An application of polytypic programming to digital searching is described in 
a companion paper [11], where we show how to define tries and operations 
on tries generically for arbitrary datatypes of first-order kind. The central 
insight is that a trie can be considered as a type-indexed datatype, which 
adds an interesting new dimension to polytypic programming. 
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A Categorical Combinators 

This appendix contains the definitions of the categorical combinators used 
in the main text. The notation is fairly standard so the cognoscenti should 
have no problems in reading the article. For background material the reader 
is referred to the textbook by R. Bird and O. de Moor [3]. 



Standard combinators id is the identity function, 'o' denotes functional 
composition, and const creates a constant-valued function. 

id :: a — > a 

id x = x 

(o) :: (&-> c) -> {a -> b) -> (a -> c) 

(/ °g)x = f (g x) 

const :: a — > b — > a 

const x y = y 
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Sums We treat sums as if they were given by the following datatype defi- 
nition. 



data a + b = Inl a \ Inr b 

(V) :: (a -> c) -> (b -> c) -> (a + & -> c) 

(fVg)(Inlx) = fx 

if V #) (Inr y) = g y 

(+) :: (a^a / )^(&^& / )^(«+^^« / + ^ / ) 

/ + 0 = {M o f) V {Inr o g) 

Elements of a + 6 are synthesized using the injection functions Inl and Inr; 
they are analysed using the 'case' operator (V). The disjoint sum is a bi- 
functor; its mapping function is given by (+). The operators (V) and (+) 
satisfy a variety of properties, among others 

Inl V Inr = id 

{fVg)oInl = f 

(/ V g) o Inr = g 

h° (/ V g) = (h o f) V (h o g) if h is strict. 

Note that, for fundamental reasons, '+' is not a categorical coproduct in 
non-strict languages such as Haskell, see, for instance [13]. 

Products Products are given by the following datatype. 2 

data a x b = (a, b) 

outl :: a x b — > a 

outl (x, y) = x 

outr :: a x b — > & 

cmtr (x, y) = y 

(V) :: (c — > a) — > (c — > 6) — > (c — > a x 6) 

if Ag) z = (f z,9 z) 

(x) :: ( a -> a') -> (6 -> 6') (a x 6 -> a' x 6') 

/ x # = (/ o ou^) A (g o outr) 



2 Note that in Haskell 'x' has an extra clement _L such that _L ^ (_L,_L). We simply 
ignore this extra element. 
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Elements of a x b are analysed using the projection functions outl and outr; 
they are synthesized using the 'split' operator (A). The product is a bifunc- 
tor, as well; its mapping function is given by (x). The properties of (A) and 
(x) are dual to those of (V) and (+). 

outl A outr = id 

outl o(/Aj) = / 

outr o (/ A g) = g 

(fAg)oh = (foh)A(goh). 



Currying curry converts a non-curried function to curried form with uncurry 
as its inverse. 

curry :: ((a, b) — > c) — > (a — > & — > c) 

curry / x y = f ( x ,y) 

uncurry :: (a — > & — > c) — > ((a, 6) — > c) 

uncurry f (x,y) = f x y 
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